-
Notifications
You must be signed in to change notification settings - Fork 780
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
W3C Trace propagator tests - switch to level 1 #4937
W3C Trace propagator tests - switch to level 1 #4937
Conversation
90bde8d
to
b43bdfb
Compare
Codecov Report
@@ Coverage Diff @@
## main #4937 +/- ##
==========================================
- Coverage 83.42% 83.39% -0.04%
==========================================
Files 296 296
Lines 12377 12377
==========================================
- Hits 10326 10322 -4
- Misses 2051 2055 +4
Flags with carried forward coverage won't be shown. Click here to find out more. |
b43bdfb
to
e785a3a
Compare
@@ -294,19 +294,13 @@ internal static bool TryExtractTracestate(string[] tracestateCollection, out str | |||
return false; | |||
} | |||
|
|||
// ValidateKey() call above has ensured the key does not contain upper case letters. | |||
if (!keySet.Add(key.ToString())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expects the tracestate to be inherited, and the duplicated keys to be either kept as-is or one of them to be discarded
Could we discard the duplicate ones instead of keeping them? We are only allowed 32 keys. Why waste them by storing duplicates when we could make room for other unique keys?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tried to answer in PR description on it what was the reason for the change:
Duplicated keys are fully propagated now. It allows to drop creating HashSet for each propagation execution. Now only counter is created.
If you think that it is worth to keep the checj, I can update this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, I think we could just keep the key as-is in favor of performance as this would be exectued in the hot-path.
@alanwest @CodeBlanch @vishweshbankwar It would be great to know your thoughts as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am good to keep this as spec allows it.
Not for this PR - It would be good to check how other languages are doing it (would be good to keep consistent behavior)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Java is doing similar things, at the beginning checking if there is more/less than 32 attributes https://github.com/open-telemetry/opentelemetry-java/blob/57d83344178f578eb5d2f043b0ffc5c42b6719a5/api/all/src/main/java/io/opentelemetry/api/trace/propagation/internal/W3CTraceContextEncoding.java#L43-L45
Go-lang has similar issue like here, before changes: https://github.com/open-telemetry/opentelemetry-go/blob/c047088605b454f172765621d53107f80b1e6417/trace/tracestate.go#L123-L126
Python is checking duplicates: https://github.com/open-telemetry/opentelemetry-python/blob/34d11d59e9b37052eb3aa6706288641ecb3056e7/opentelemetry-api/src/opentelemetry/trace/span.py#L231-L240
I do not think that there we will be able to find common solution.
Cross-posting open-telemetry/opentelemetry-go#4638 (comment) |
Assert.Equal("foo=1,foo=1", CallTraceContextPropagator("foo=1,foo=1")); | ||
Assert.Equal("foo=1,foo=2", CallTraceContextPropagator("foo=1,foo=2")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the correct behavior or is the behavior in @pellared's PR for opentelemetry-go correct? That is:
Assert.Equal("foo=1,foo=1", CallTraceContextPropagator("foo=1"));
Assert.Equal("foo=1,foo=2", CallTraceContextPropagator("foo=1"));
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, nevermind. After speaking with @utpilla, sounds like both behaviors are correct and left up to the implementation.
Not sure I understand... should this PR become a draft too because the W3C spec has not yet clarified the behavior? |
Also because W3C spec is not released. |
@pellared I don't follow. Are there any specific links that you're looking at to determine the readiness of the W3C spec? We are trying to find out if it's okay for us to merge the changes proposed in this PR. |
CC @reyang |
I will try to add more comment here. When the docker test image the latest commit from opentelemetry-dotnet/test/OpenTelemetry.Instrumentation.W3cTraceContext.Tests/Dockerfile Line 12 in 1ec7a63
There are 2 versions of the specification:
Changes in tests w3c/trace-context#477 was merged in 2022, so after the Level 1 was released. I see two options to proceed here:
For both cases test suited should be fetched from exact commit instead of the latest main. |
I think we should aim for complying with the stable spec. @alanwest Thoughts? |
This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day. |
c52d2a4
to
f6b2d2a
Compare
@utpilla, @alanwest, @vishweshbankwar, please review once more time. The PR is fully changed - tests are now executed based on Level 1 of specification (and passing on .NET7). See: f6b2d2a |
.NET8 failure seems to be unrelated to changes. Please rerun. |
Fixes test_tracestate_duplicated_keys from w3c test suiteFollow up to #4893, there will be one more PR to fix random flags.Ref: https://github.com/w3c/trace-context/blob/551a5b0855171281e98b4c2a814bf9e1f837cd53/test/test.py#L565-L567Changes
Duplicated keys are fully propagated now. It allows to drop creating HashSet for each propagation execution. Now only counter is created.Opposite option, propagate only one value for given key. I think that it requires keeping HashSet.Switch W3C Trace tests to level 1, based on: #4937 (comment)
Merge requirement checklist
[ ] AppropriateCHANGELOG.md
files updated for non-trivial changes[ ] Changes in public API reviewed (if applicable)